Many software programs contain complex data structures, and software developers rely on predefined libraries data structures (e.g. classes), or create their own libraries. In these cases, when a developer encounters a debugging problem in executing a software program, they are sometimes more interested in investigating the abstract contents of the data structures, i.e., the attributes of their interests during the execution of the software program, rather than the physical structures used to represent the abstract contents. Unfortunately, existing debugging systems or “debuggers” often present developers with internal details of these structures, which makes it difficult to determine the abstract contents of actual interest. For example, the developer might use a data structure called a List to represent an ordered collection of items on an invoice. In the debugger, the developer might wish to see the list of items and their attributes (e.g., quantity, price, description). However, internally the List data structure is implemented as a linked list of nodes. Therefore, in order to understand or monitor the contents of the List using a prior art debugger, the developer has to follow a long series of pointers between nodes and examine variables names along the way, such as nodeptr and nextptr that have little to do with the list of invoice items the developer wants to monitor.
In some cases, this extraneous information can include details of the data structures created by the supplier of a library, and for which the developer may have poor facilities for understanding. Even if the developer understands the objects and structures, the problem they are addressing may be focused on the abstract content represented by the data structure, rather than the physical structure.
In addition to these problems, some existing software debuggers provide little or no control over the format for presentation of the information and have little or no editing capability for data values within objects or data structures. Thus, in many cases, the software developer is presented with unwanted information, rigidly formatted, and with limited or no editing capability.
In addition to the difficulties discussed above, debugging of Java Server Pages (JSP pages) presents a unique set of difficulties. These difficulties arise from a number of sources inherent in the way JSP pages are developed and deployed. In many cases, the code executed to implement the JSP page is “machine generated” and is embedded into a servlet running in a complex runtime environment. Thus, it may be very difficult for a developer to understand the mapping between the JSP source code they have created and wish to debug, and the machine generated code they would see through an existing debugger applied to the runtime environment. Further complicating this situation is the common use of tags that redirect the execution path within the JSP page. Also, JSP pages also consume and produce streams of data.